คู่มือรีสตาร์ทเซอร์วิส hpe-restd และ yang-resolverd บน ArubaOS-CX

ข้อมูลเชิงลึกสำหรับผู้เชี่ยวชาญด้านเครือข่าย

1. บทนำเกี่ยวกับเซอร์วิส `hpe-restd` และ `yang-resolverd`

ArubaOS-CX เป็นระบบปฏิบัติการเครือข่ายที่ทันสมัยสำหรับสวิตช์ Aruba CX Series ซึ่งเน้นสถาปัตยกรรมแบบโมดูลาร์และโปรแกรมได้ เซอร์วิส `hpe-restd` และ `yang-resolverd` มีบทบาทสำคัญในการจัดการและการทำงานของสวิตช์เหล่านี้ ส่วนนี้จะอธิบายถึงสถาปัตยกรรมของ ArubaOS-CX และหน้าที่หลักของเซอร์วิสทั้งสอง

1.1 สถาปัตยกรรม ArubaOS-CX: รากฐานของความยืดหยุ่น

ArubaOS-CX ถูกสร้างขึ้นด้วยแนวทาง "Cloud-Native" เป็นระบบแบบโมดูลาร์ สามารถโปรแกรมได้ ยืดหยุ่นสูง และทนทานต่อความผิดพลาด ใช้รูปแบบไมโครเซอร์วิส โดยฟังก์ชันต่างๆ ถูกแบ่งการทำงานไปยังเดมอนที่แยกจากกัน มีฐานข้อมูลสถานะพร้อม REST API 100% ทำให้สามารถโปรแกรมและทำงานอัตโนมัติได้สมบูรณ์ ช่วยให้รีสตาร์ทเซอร์วิสเฉพาะส่วนได้โดยไม่กระทบทั้งระบบ โดยเฉพาะระนาบข้อมูล (data plane)

1.2 เดมอน `hpe-restd`: ประตูสู่การจัดการ

เดมอน HPE REST (`hpe-restd`) เป็นเซอร์วิสสำคัญในระนาบการจัดการ มีหน้าที่หลัก:

  • เกตเวย์ REST API: อินเทอร์เฟซหลักสำหรับการโต้ตอบผ่าน REST API
  • การเชื่อมต่อ Aruba Central: จัดการการเชื่อมต่อกับ Aruba Central (provisioning, data collection, monitoring)
  • แบ็กเอนด์ Web UI: สนับสนุนการทำงานของ Web UI ของสวิตช์
  • การจัดเตรียมและการรวบรวมข้อมูล: อำนวยความสะดวกในการตั้งค่าและรวบรวมข้อมูลการดำเนินงาน
  • ระบบย่อยการแจ้งเตือน: จัดการการแจ้งเตือนแบบเรียลไทม์ไปยังไคลเอ็นต์ที่สมัครรับข้อมูล (เช่น Central)

ความเสถียรของ `hpe-restd` สำคัญต่อการจัดการระยะไกลและระบบอัตโนมัติ

1.3 เดมอน `yang-resolverd`: ผู้ดูแลโมเดลข้อมูล

เดมอน `yang-resolverd` จัดการและซิงโครไนซ์ข้อมูลของสวิตช์ตามโมเดลข้อมูล YANG มีหน้าที่หลัก:

  • การประมวลผลโมเดลข้อมูล YANG: ตีความ ตรวจสอบ และประมวลผลข้อมูลตามโมเดル YANG
  • การซิงโครไนซ์ข้อมูลกับระบบจัดการ: อำนวยความสะดวกในการแสดงผลและซิงโครไนซ์สถานะและการกำหนดค่ากับแพลตฟอร์มภายนอก (เช่น Aruba Central)

`yang-resolverd` สำคัญต่อความแม่นยำของระบบตรวจสอบและจัดการเครือข่าย ปัญหาเกี่ยวกับเดมอนนี้อาจนำไปสู่ข้อมูลที่ทำให้เข้าใจผิดในแดชบอร์ดการจัดการ

2. ข้อควรระวังทั่วไปและแนวทางปฏิบัติที่ดีที่สุด

การรีสตาร์ทเซอร์วิสใดๆ บนสวิตช์ในสภาพแวดล้อมการทำงานจริงควรดำเนินการด้วยความระมัดระวัง ส่วนนี้จะสรุปข้อควรปฏิบัติเพื่อลดผลกระทบที่อาจเกิดขึ้น

การวางแผนและเตรียมการ

  • ปฏิบัติตามระเบียบการจัดการการเปลี่ยนแปลง (Change Management) ขององค์กรเสมอ
  • สำรองข้อมูลการกำหนดค่าล่าสุดของสวิตช์ (`copy running-config startup-config` และ off-box backup)
  • กำหนดเวลารีสตาร์ทในช่วงเวลาบำรุงรักษาตามแผน (Scheduled Maintenance Windows)

การดำเนินการและตรวจสอบ

  • ทำความเข้าใจผลกระทบที่อาจเกิดขึ้นกับเซอร์วิส (เช่น `hpe-restd` จะทำให้ Web UI/Central หยุดชะงักชั่วคราว)
  • ทำการเปลี่ยนแปลงทีละขั้นตอน (รีสตาร์ทเซอร์วิสทีละตัว) เพื่อการวินิจฉัยที่แม่นยำ
  • ตรวจสอบบันทึกเหตุการณ์ของระบบ (System Logs) ก่อนและหลังการรีสตาร์ท

ข้อควรจำ: การรีสตาร์ทเซอร์วิสโดยขาดความรอบคอบอาจนำไปสู่การหยุดชะงักของการจัดการหรือบดบังปัญหาที่แท้จริงได้

3. คู่มือเชิงลึก: การรีสตาร์ทเซอร์วิส `hpe-restd`

ส่วนนี้จะให้รายละเอียดเกี่ยวกับฟังก์ชัน, สถานการณ์ที่ควรพิจารณารีสตาร์ท, ขั้นตอนการวินิจฉัย, วิธีการรีสตาร์ท, และผลกระทบของการรีสตาร์ทเซอร์วิส `hpe-restd`

3.1 ฟังก์ชันและความรับผิดชอบโดยละเอียดของ `hpe-restd`

`hpe-restd` เป็นศูนย์กลางสำหรับอินเทอร์เฟซการจัดการภายนอก จัดการการรับรองความถูกต้องเซสชัน REST (Event ID 4602/4601), เซสชันผู้ใช้ (Event ID 4604/4605), และการให้สิทธิ์ (Event ID 4607/4608/4606) นอกจากนี้ยังเกี่ยวข้องกับการเชื่อมต่อ Aruba Central (Event ID 4632/4639 สำหรับการเชื่อมต่อ, 4633/4634 สำหรับการตัดการเชื่อมต่อโดย Central, 4637 สำหรับข้อผิดพลาดภายใน) และการจัดการใบรับรองผ่าน WebUI

3.2 สถานการณ์ที่ควรพิจารณารีสตาร์ท `hpe-restd`
  • ปัญหาการเชื่อมต่อ Aruba Central (สวิตช์ออฟไลน์, `connection_failure`)
  • Web UI ไม่ตอบสนองหรือล้มเหลว
  • REST API ล้มเหลว หรือ Central/NetEdit หมดเวลาเมื่อเรียก API
  • `hpe-restd` ขัดข้องหรือสร้าง Core Dumps
  • หลังจากการอัปโหลดใบรับรองที่ไม่ถูกต้องผ่าน WebUI
3.3 การวินิจฉัยเบื้องต้นก่อนรีสตาร์ท `hpe-restd` (ตารางที่ 1)

ควรรวบรวมข้อมูลต่อไปนี้ *ก่อน* การรีสตาร์ท:

คำสั่งContextรายละเอียด/วัตถุประสงค์
show version> หรือ #ตรวจสอบเวอร์ชันเฟิร์มแวร์
show aruba-central
(หรือ show hpe-anw-central)		> หรือ #ตรวจสอบสถานะการเชื่อมต่อ Aruba Central
show events -d hpe-restd -r -n 50#แสดง Log 50 รายการล่าสุดจาก `hpe-restd`
show security-logs -d hpe-restd -r -n 50#แสดง Security Log 50 รายการล่าสุดจาก `hpe-restd`
show core-dump#ตรวจสอบ Core Dumps จาก `hpe-restd`
diag-dump rest basic#รวบรวมข้อมูลวินิจฉัยพื้นฐานของ REST feature
show system resource-utilization> หรือ #ตรวจสอบการใช้งาน CPU และหน่วยความจำ
debug rest all [severity error]#เปิดใช้งาน Debug Log (ใช้ด้วยความระมัดระวัง)
3.4 ขั้นตอนการรีสตาร์ท `hpe-restd`
  1. เข้าถึง CLI ของสวิตช์ (สิทธิ์ manager)
  2. เข้าสู่ Diagnostic Shell:
    start-shell
  3. ยกระดับสิทธิ์ (หากจำเป็น):
    sudo bash
  4. รีสตาร์ทเซอร์วิส `hpe-restd`:
    systemctl restart hpe-restd
  5. ออกจาก `sudo bash`:
    exit
  6. ออกจาก Diagnostic Shell:
    exit
3.5 การตรวจสอบหลังการรีสตาร์ท `hpe-restd`
  • ตรวจสอบสถานะเซอร์วิส (จาก shell): `systemctl status hpe-restd` (ควรเป็น "active (running)")
  • ตรวจสอบการเชื่อมต่อ Aruba Central (จาก CLI): `show aruba-central` (ควรเป็น "connected")
  • ทดสอบ Web UI และ REST API (ถ้าใช้งาน)
  • ตรวจสอบ Log ล่าสุด (`show events -r -n 20`) เพื่อหา Error ใหม่
  • ยืนยันว่าอาการเดิมได้รับการแก้ไข
3.6 ผลกระทบระหว่างการรีสตาร์ท `hpe-restd`
  • **การไม่สามารถจัดการชั่วคราว:** Web UI, REST API, Aruba Central จะหยุดชะงัก
  • **การสิ้นสุดเซสชัน:** เซสชัน Web UI/REST API ที่มีอยู่จะถูกยกเลิก
  • **การดำเนินการกำหนดค่า:** Config ที่กำลังส่งอาจล้มเหลว
  • **Core Dumps:** อาจเกิด Core Dump ในบางกรณี แม้การรีสตาร์ทจะสำเร็จ
  • **ไม่มีผลกระทบต่อระนาบข้อมูล:** โดยทั่วไปไม่ส่งผลต่อการส่งต่อแพ็กเก็ต

4. คู่มือเชิงลึก: การรีสตาร์ทเซอร์วิส `yang-resolverd`

ส่วนนี้จะให้รายละเอียดเกี่ยวกับฟังก์ชัน, สถานการณ์ที่ควรพิจารณารีสตาร์ท, ขั้นตอนการวินิจฉัย, วิธีการรีสตาร์ท, และผลกระทบของการรีสตาร์ทเซอร์วิส `yang-resolverd`

4.1 ฟังก์ชันและความรับผิดชอบโดยละเอียดของ `yang-resolverd`

`yang-resolverd` รับผิดชอบความสมบูรณ์และการซิงโครไนซ์ข้อมูลที่สร้างแบบจำลองด้วย YANG ของสวิตช์กับระบบภายนอก (โดยเฉพาะ Aruba Central) ทำให้มั่นใจว่าโครงสร้างข้อมูลที่แสดงสถานะสวิตช์ (เช่น ตารางไคลเอ็นต์) ได้รับการประมวลผลอย่างถูกต้อง

4.2 สถานการณ์ที่ควรพิจารณารีสตาร์ท `yang-resolverd`
  • **ข้อมูลไม่ตรงกันใน Aruba Central:** เหตุผลที่พบบ่อยที่สุดคือรายการไคลเอ็นต์ไม่แสดงหรือแสดงไม่ถูกต้องใน Central
  • ข้อมูลสวิตช์อื่นๆ ที่แสดงใน Central หรือ NMS ล้าสมัยหรือไม่ถูกต้อง (แม้จะไม่ค่อยมีบันทึกไว้)
4.3 การวินิจฉัยเบื้องต้นก่อนรีสตาร์ท `yang-resolverd` (ตารางที่ 2)

การวินิจฉัยมักอาศัยการสังเกตอาการในระบบภายนอก:

อาการ/ตัวชี้วัดส่วนที่น่าจะได้รับผลกระทบบันทึก/คำสั่งที่เกี่ยวข้อง
รายการไคลเอ็นต์ไม่แสดง/ไม่ถูกต้องใน Centralการซิงโครไนซ์ข้อมูล`show aruba-central`, Central UI, Event Logs
ข้อมูลสวิตช์ล้าสมัยใน NMSการประมวลผล/ซิงค์โมเดลข้อมูลNMS Logs/Status, Event Logs สวิตช์
ข้อผิดพลาด "Subscription not found" (คาดการณ์)การจัดการ Subscription YANGEvent Logs, NMS Logs

ตรวจสอบ `show version` และ `show events -r -n 50` ด้วย

4.4 ขั้นตอนการรีสตาร์ท `yang-resolverd`
  1. เข้าถึง CLI ของสวิตช์ (สิทธิ์ manager)
  2. เข้าสู่ Diagnostic Shell:
    start-shell
  3. ยกระดับสิทธิ์ (หากจำเป็น):
    sudo bash
  4. รีสตาร์ทเซอร์วิส `yang-resolverd`:
    systemctl restart yang-resolverd
  5. ออกจาก `sudo bash`:
    exit
  6. ออกจาก Diagnostic Shell:
    exit
4.5 การตรวจสอบหลังการรีสตาร์ท `yang-resolverd`
  • ตรวจสอบสถานะเซอร์วิส (จาก shell): `systemctl status yang-resolverd` (ควรเป็น "active (running)")
  • ตรวจสอบความถูกต้องของข้อมูลใน Aruba Central (รีเฟรช UI)
  • ตรวจสอบ Log ล่าสุด (`show events -r -n 20`)
  • ยืนยันว่าอาการข้อมูลไม่ถูกต้องได้รับการแก้ไข
4.6 ผลกระทบระหว่างการรีสตาร์ท `yang-resolverd`
  • **ข้อมูลไม่ถูกต้องชั่วคราว:** ข้อมูลใน Central/NMS อาจไม่สมบูรณ์หรือล้าสมัยชั่วขณะ
  • **การสร้าง Subscription ใหม่:** Data subscriptions สำหรับ NMS อาจถูกยกเลิกและต้องสร้างใหม่
  • **การใช้ทรัพยากร:** CPU/หน่วยความจำอาจเพิ่มขึ้นเล็กน้อยชั่วขณะ
  • **ไม่มีผลกระทบโดยตรงต่อระนาบข้อมูล:** ไม่ควรส่งผลต่อการส่งต่อทราฟฟิก

5. ความเข้าใจในการจัดการเซอร์วิสด้วย `systemd`

ArubaOS-CX ใช้ `systemd` เป็นระบบ init และตัวจัดการเซอร์วิส ซึ่งเป็นมาตรฐานใน Linux สมัยใหม่ ส่วนนี้อธิบายภาพรวมการทำงานของ `systemd` และคำสั่ง `systemctl restart`

5.1 ภาพรวมของ `systemd` ใน AOS-CX

`systemd` รับผิดชอบในการเริ่มต้น, หยุด, ตรวจสอบ, และจัดการเดมอน (เซอร์วิส) ของระบบ เซอร์วิสต่างๆ ถูกกำหนดใน unit files ซึ่งระบุวิธีการจัดการ, การขึ้นต่อกัน (dependencies), และวิธีการเริ่มต้น/หยุด

5.2 กระบวนการ `systemctl restart ` (ตารางที่ 3)

เมื่อรันคำสั่ง `systemctl restart `:

  1. `systemd` พยายามหยุดเซอร์วิสอย่างนุ่มนวล (gracefully) โดยส่งสัญญาณ `SIGTERM`
  2. เซอร์วิสควรดักจับ `SIGTERM` และปิดระบบอย่างสะอาด (บันทึกสถานะ, ปิดไฟล์)
  3. `systemd` รอเป็นระยะเวลาหนึ่ง (ค่าเริ่มต้น 90 วินาที)
  4. หากเซอร์วิสไม่สิ้นสุด, `systemd` ส่งสัญญาณ `SIGKILL` (บังคับหยุดทันที)
  5. หลังจากเซอร์วิสหยุด, `systemd` เริ่มต้นเซอร์วิสใหม่
ขั้นตอนการดำเนินการโดย `systemd`สัญญาณเวลารอ (ค่าเริ่มต้น)วัตถุประสงค์
1. พยายามหยุดอย่างนุ่มนวลส่งสัญญาณยุติการทำงานSIGTERM90 วินาทีอนุญาตให้เซอร์วิสปิดระบบอย่างสะอาด
2. หมดเวลา & บังคับหยุดหากไม่สิ้นสุดหลังหมดเวลาSIGKILLN/Aบังคับยุติเซอร์วิสที่ไม่ตอบสนอง
3. เริ่มการทำงานเริ่มเซอร์วิสใหม่N/AN/Aทำให้เซอร์วิสกลับมาออนไลน์
5.3 การขึ้นต่อกันของเซอร์วิสและการรักษาสถานะ

`systemd` จัดการการขึ้นต่อกันระหว่างเซอร์วิส การรีสตาร์ทเซอร์วิสหนึ่งอาจส่งผลต่อเซอร์วิสที่ขึ้นต่อกัน การปิดระบบอย่างนุ่มนวล (จัดการ `SIGTERM`) สำคัญสำหรับเซอร์วิสที่ต้องการรักษาสถานะ ขอบเขตที่ `hpe-restd` และ `yang-resolverd` รักษาสถานะระหว่างรีสตาร์ทขึ้นอยู่กับการออกแบบภายใน (เอกสารทางการไม่ได้ให้รายละเอียด)

6. การแก้ไขปัญหาขั้นสูงและการส่งต่อปัญหา (Escalation)

เมื่อการรีสตาร์ทเซอร์วิสไม่สามารถแก้ไขปัญหาได้ หรือปัญหาเกิดขึ้นซ้ำๆ แสดงว่ามีปัญหาที่ซับซ้อนกว่านั้น ส่วนนี้จะแนะนำขั้นตอนต่อไป

6.1 เมื่อการรีสตาร์ทไม่เพียงพอ

หากการรีสตาร์ทไม่ช่วยแก้ปัญหา หรือปัญหาเกิดซ้ำ บ่งชี้ถึงปัญหาพื้นฐานที่ยังอยู่ อาจเกิดจาก Firmware Bug, Resource หมด, Config ขัดแย้ง, หรือปัญหา Hardware

6.2 การรวบรวมข้อมูลการวินิจฉัยที่ครอบคลุมสำหรับ TAC
  • `show tech` (สำคัญมาก): รวบรวมข้อมูลสนับสนุนทางเทคนิคโดยละเอียด
  • Core Dumps: หากพบ ให้รวบรวมด้วย `copy core-dump `
  • บันทึกดีบักเฉพาะ: TAC อาจขอให้เปิดใช้งาน (เช่น `debug rest all severity debug`)
  • Packet Captures: สำหรับปัญหาการเชื่อมต่อ (`diag utilities tshark`)
6.3 การติดต่อศูนย์ให้ความช่วยเหลือทางเทคนิคของ Aruba (TAC)

เตรียมข้อมูลการวินิจฉัยทั้งหมด รวมถึง:

  • คำอธิบายปัญหาและอาการ
  • เวอร์ชันเฟิร์มแวร์ (`show version`)
  • ขั้นตอนที่ดำเนินการไปแล้ว (รวมถึงผลการรีสตาร์ทเซอร์วิส)
  • บันทึกที่เกี่ยวข้อง (`show events`, security logs, `show tech`, core dumps)
  • โทโพโลยีเครือข่ายและการเปลี่ยนแปลงล่าสุด

7. สรุปและประเด็นสำคัญ

การทำความเข้าใจบทบาทและการจัดการเซอร์วิส `hpe-restd` และ `yang-resolverd` บนสวิตช์ ArubaOS-CX เป็นสิ่งจำเป็นสำหรับวิศวกรเครือข่าย การรีสตาร์ทเซอร์วิสเหล่านี้เป็นเทคนิคการแก้ไขปัญหาขั้นสูง ซึ่งควรทำด้วยความระมัดระวังและเมื่อมีเหตุผลอันสมควร

`hpe-restd`

  • เดมอนหลักสำหรับ REST API, Web UI, และการสื่อสารกับ Aruba Central
  • การรีสตาร์ทสามารถแก้ไขปัญหาการเชื่อมต่อ/การจัดการ แต่จะทำให้การจัดการหยุดชะงักชั่วคราว

`yang-resolverd`

  • รับผิดชอบความถูกต้องของข้อมูล YANG ที่จำเป็นสำหรับ Central
  • การรีสตาร์ทมักแก้ไขปัญหาข้อมูลไม่ถูกต้อง/ขาดหายไปใน Central

ประเด็นสำคัญเพิ่มเติม:

  • การรีสตาร์ททำผ่าน `start-shell` -> `sudo bash` -> `systemctl restart `
  • ควรทำการวินิจฉัยเบื้องต้นและปฏิบัติตามแนวทางที่ดีที่สุด (Change Management, Backup)
  • โดยทั่วไปไม่ส่งผลกระทบต่อ Data Plane แต่กระทบ Management Plane ชั่วคราว
  • หากปัญหายังคงอยู่ จำเป็นต้องตรวจสอบเชิงลึกและอาจต้องส่งต่อปัญหาไปยัง Aruba TAC

สถาปัตยกรรมแบบโมดูลาร์ของ ArubaOS-CX ช่วยให้สามารถรีสตาร์ทเซอร์วิสเป้าหมายได้ ซึ่งเป็นข้อได้เปรียบในการปฏิบัติงาน ช่วยลดเวลาหยุดทำงานของการจัดการและเพิ่มความพร้อมใช้งานของเครือข่ายโดยรวม